| Attribute | Description | Alabama | Connecticut | Hawaii | Minnesota | Nebraska | New Mexico | New York City | Oregon | Rhode Island | Wisconsin |
|---|---|---|---|---|---|---|---|---|---|---|---|
| Date | The date this questionnaire was answered and for which the anwers are accurate. | 6/19/12 | 7/9/12 | 6/14/12 | 6/5/12 | 7/6/12 | 6/15/12 | 7/5/12 | 6/15/12 | 7/6/12 | 06/14/12 |
| Name | The person associated with the organization that answered the questionnaire. | Ben McGhee | DF | Gail Ogawa | Emily Emerson | Michelle Hood | Kevin Bersell | Kristen Forney | Michelle Barber | Kim Salisbury-Keith | Kevin Samuelson Business Analyst HP |
| IIS Name | Official name of immunization information system. | Alabama - ImmPRINT | Hawaii Immunization Registry | NESIIS (Nebraska State Immunization Information System) | NMSIIS | NYC Citywide Immunization Registry | ALERT IIS | KIDSNET | WIR (Wisconsin) | ||
| Attributes of the Transport Layer | Alabama | Connecticut | Hawaii | Minnesota | Nebraska | New Mexico | New York City | Oregon | Rhode Island | Wisconsin | |
| Manual User Upload | User must login to the IIS and manually upload data. This is a non-automated process. | Yes
Alabama developed a Web Service Client that allows providers to consume our Web Service and upload a message. |
No
We do not have any function within the application to upload a file. We are working with HL7 format that can be converted to MAVEN Integration format for the application to consume. At this point only external partners that are using PHIN MS or manual process of posting and pulling file from a secure FTP are available for a predefined period until another better transport is in place. |
Yes | Yes
There is manual intervention to release into IIS. |
Yes | Yes | No
This option is available for our flat file interface, but not for HL7 |
Yes
27 organizations upload their own data (9 of which send HL7) |
Yes
For our Web file Repository (WFR), |
Yes |
| Synchronous Transport | Uses a method that supplies two-way synchronous connection such that the sender can submit a single message and implicitly supports returning a response message associated with the request. Common technologies used: Web Service, HTTPS POST, PHIN-MS. | Yes
Alabama uses Web Service. |
Yes
PHIN MS is in place with both sender and receiver Obliviously this will be the much needed requirement for providers and every provider wishes to have this functionality at the earliest. |
No
After web service development is complete: Yes |
Yes | Yes | No
Currently: No |
Yes
CIR uses a bi-directional SOAP Web Service for synchronous transport. As of today, 221 sites are reporting to us through the web service. |
Yes
132 sites (represented by 9 sending organizations) use SOAP web-services |
Yes
Have HTTPS POST |
Yes |
| Asynchronous Transport | Uses a method that supplies a two-way asynchronous interface such that the sender can submit a message but the technology does not supply an implicit reply. A reply may be sent, but only in newly created connection. A good example of this is secure File Transfer Protocol (FTP). | No | Yes
To start with we have to allow Asynchronous transport for those practices using a batch method. Especially small time clinics vastly depend on this. |
No | Yes
When updates are sent Asynchronously it isn't automated. There is manual intervention to release into IIS. |
No | No
Currently: No |
No
This option is available only for flat files, not HL7 |
Yes
70 organizations submit files in files that we pre-process before uploading for them; 2 organizations send HL7, 2 send Flat File that we load. Currently accept data via FTP and HTTPs, and sFTP by Fall we will only accept files via sFTP. |
Yes
WFR provides secure file transfer that is Asynchronous |
No
A response/reply is always generated for the inbound messages. |
| Attributes of IIS Processing | Alabama | Connecticut | Hawaii | Minnesota | Nebraska | New Mexico | New York City | Oregon | Rhode Island | Wisconsin | |
| Scheduled Update Processing | Updates are queued for processing until a later time, usually overnight. The IIS may accept and acknowledge the message immediately but the data is processed later. | No | Yes
To start with we have to allow Asynchronous transport. |
No | No | No | Yes
It's all manual, using an SFTP system |
No | No | Yes | Yes
Via a manual upload a file will be processed as soon as possible (it isn't queued to run at a particular point in the day/evening). However, depending upon the amount of data exchange occurring at that point, the job may not run immediately, but within minutes. Via PHIN-MS, a file containing 10 or more messages will be statged to the batch process and processed as soon as possible. |
| Immediate Update Processing | Updates are immediately processed and consumed in their entirety. Once the IIS acknowledges the message the data is available to regular IIS users. | Yes | Yes | Yes | Yes | Yes | No
Currently: No |
Yes | Yes | No | Yes
This is the case for messages with or without errors. WIR returns a response to the provider indicating if the message was accepted and/or contains hard/soft errors. |
| Immediate Status Notification | After updates are processed immediately, IIS sends an acknowledgement (ACK) to indicate any errors in the data that may have affected processing. | Yes | Yes | Yes | Yes | Yes | No
Currently: No |
Yes
Updates are processed in real-time, and the ACK that is returned to the sending system indicates whether the message was processed successfully and contains information about any processing errors (both fatal and non-fatal); also includes the patient's CIR ID number which can be stored by the sending system for future updates or queries. |
Yes | Yes
ACK needs additional testing |
Yes |
| Holds for Manual Reviews | Updates that require human review, because the exact patient match was not found, are held until reviewed by IIS staff. This hold means that all or some of the data submitted is unavailable for viewing until reviewed. | No
If the exact patient is not found Alabama will send an ACK indicating exact match was not found. There is no holds for manual reviews. |
Yes
This is one of the basic requirements; all of the questionable records are stored in a workflow |
Yes
Pending files are not viewable via the user interface until the manual review process is completed. |
Yes
This happens if 2 or more possible matches exist. |
Yes | Yes | No | Yes
Pending files are held until reviewed, and are not visible in the transactional database until post-review. |
Yes | Yes
WIR has a matching algrothim which scores potential matches. If there is the possibility of more than 1 match, the inbound message will be loaded to a pending status. At this point a representative from the State reviews and merges the records or creates a new patient record if appropriate. |
| Scheduled Query Processing | Queries can be processed in batches at a scheduled or regular time. The query process may be scheduled or manual. | No
Alabama does not support queries in batch. |
Yes
Will need to determine which systems are batch versus real time |
Yes | No | No | No
Currently: No |
No | Yes
While this functionality exists, we do not use it or advertise that it is available. |
No
No Query capacity at this time |
Yes |
| Immediate Query Response | Queries can be run and responses returned in a similar amount of time as that which is expected for users who query using the IIS web interface. | Yes | Yes
This is similar to Synchronous process this will work for real time |
Yes | Yes | Yes | No
Currently: No |
Yes
99 sites have a bi-directional interface and are dong real-time queries |
Yes
27 sites send VXQ messages via SOAP web services |
No
No Query capacity at this time |
Yes
Web Services and PHIN-MS |